Dynomotion

Group: DynoMotion Message: 12365 From: Eduardo Barocio Date: 10/8/2015
Subject: Read execution done from C-program
Hi all, 

I'm new using the Kflop controller and I'm wondering if someone could help with the following two questions. 

I'm working on an application where I need to do the following:
- I execute a C-program using an M code (example below with M101),
    This C-program basically sends a couple of commands to an extruder (Stop) and some other peripheral devices. However, I need to know when the next G-code (G0 X30. Y... in the example below) line has been executed in order to start the extruder again. This is basically for turning on and off the extruder.   
 I've tried to use the CheckDone command without success, and to monitor the current destination of the individual channels, but I've set the motion planner to perform continuous trajectories, so I can't detect when it finishes executing the fast movement command.

G01 X100. Y50. Z14.
G01 X20. Y50. Z14
M101
G0 X30. Y40. Z14.
G01 X10. Y40. Z14.

So my questions are:
Is it possible to retrieve the position to go (commanded position) from the motion planner? If do so, what's the register that I need to look at?,
On the other hand, I know that commands are loaded into a buffer prior to execution, (based on the look ahead parameter). So my question would be, where is this register located?

I would appreciate any help and I'm open to any suggestions. 

Thanks in advance, 


 
Group: DynoMotion Message: 12366 From: Tom Kerekes Date: 10/8/2015
Subject: Re: Read execution done from C-program
Hi Edwardo,

Why not include another M Code to turn the extruder back on?

Regards
TK

On 10/8/2015 9:23 AM, Eduardo Barocio vbedwuard_25@... [DynoMotion] wrote:
 
Hi all, 

I'm new using the Kflop controller and I'm wondering if someone could help with the following two questions. 

I'm working on an application where I need to do the following:
- I execute a C-program using an M code (example below with M101),
    This C-program basically sends a couple of commands to an extruder (Stop) and some other peripheral devices. However, I need to know when the next G-code (G0 X30. Y... in the example below) line has been executed in order to start the extruder again. This is basically for turning on and off the extruder.   
 I've tried to use the CheckDone command without success, and to monitor the current destination of the individual channels, but I've set the motion planner to perform continuous trajectories, so I can't detect when it finishes executing the fast movement command.

G01 X100. Y50. Z14.
G01 X20. Y50. Z14
M101
G0 X30. Y40. Z14.
G01 X10. Y40. Z14.

So my questions are:
Is it possible to retrieve the position to go (commanded position) from the motion planner? If do so, what's the register that I need to look at?,
On the other hand, I know that commands are loaded into a buffer prior to execution, (based on the look ahead parameter). So my question would be, where is this register located?

I would appreciate any help and I'm open to any suggestions. 

Thanks in advance, 


 
Group: DynoMotion Message: 12367 From: Eduardo Barocio Date: 10/8/2015
Subject: Re: Read execution done from C-program
Hi Tom, 

The problem is that I don't have full control on the g-code generator (3d printer slicer) and I've been using two M codes by plugging them in manually into the code so far. I thought that it would be easier to tackle this problem from the gcode interpreter than from the g-code generator.
Additionally, they reason why I would like to look ahead into the gcode is because I want to turn off the extruder before getting to the M code (stop extruder), in order to reduce oozing during the fast movement.   

Thanks Tom, 
 
Regards Edward,





On Thursday, October 8, 2015 12:49 PM, "Tom Kerekes tk@... [DynoMotion]" <DynoMotion@yahoogroups.com> wrote:


 
Hi Edwardo,

Why not include another M Code to turn the extruder back on?

Regards
TK

On 10/8/2015 9:23 AM, Eduardo Barocio vbedwuard_25@... [DynoMotion] wrote:
 
Hi all, 

I'm new using the Kflop controller and I'm wondering if someone could help with the following two questions. 

I'm working on an application where I need to do the following:
- I execute a C-program using an M code (example below with M101),
    This C-program basically sends a couple of commands to an extruder (Stop) and some other peripheral devices. However, I need to know when the next G-code (G0 X30. Y... in the example below) line has been executed in order to start the extruder again. This is basically for turning on and off the extruder.   
 I've tried to use the CheckDone command without success, and to monitor the current destination of the individual channels, but I've set the motion planner to perform continuous trajectories, so I can't detect when it finishes executing the fast movement command.

G01 X100. Y50. Z14.
G01 X20. Y50. Z14
M101
G0 X30. Y40. Z14.
G01 X10. Y40. Z14.

So my questions are:
Is it possible to retrieve the position to go (commanded position) from the motion planner? If do so, what's the register that I need to look at?,
On the other hand, I know that commands are loaded into a buffer prior to execution, (based on the look ahead parameter). So my question would be, where is this register located?

I would appreciate any help and I'm open to any suggestions. 

Thanks in advance, 


 
Group: DynoMotion Message: 12369 From: Tom Kerekes Date: 10/8/2015
Subject: Re: Read execution done from C-program
Hi Edward,

There is a variable in the latest Test Versions called CS0_DoingRapid that should indicate a Rapid (G0) motion is currently in progress.  But unfortunately I don't think that will help with any lookahead.  Looking ahead in the coordinated motion buffer or the G Code is likely to be very complicated for many reasons.

One approach I've used on various systems in situations like this is to use a digitally delayed trajectory.  In this way the extruder commands can be created and embedded synchronously in the motion trajectory as if the extruder had no delay.  But then by delaying the commanded trajectory (and not the extruder commands) then the extruder commands will occur in the future relative to the trajectory path.  This does involve extra KFLOP Axes.  Normally 3 "dummy" axes are needed to generate the xyz (undelayed) trajectory, and an additional 3 axes to actually drive the motors and follow the delayed trajectory derived from the dummy axes.

If this sounds like something you would want to try I can supply further details.  See the attached example.

HTH
Regards
TK


Group: DynoMotion Message: 12370 From: Eduardo Barocio Date: 10/8/2015
Subject: Re: Read execution done from C-program [1 Attachment]
Hi Tom, 

I think that it's a great idea and could work for what I'm trying to do, since the extruder takes about a second to both: start and stop, so I need to do both actions ahead of the trajectory. I would appreciate it if you could give me further details. 
Regarding the code that you shared me,  if I understood well, the motion is computed using the dummy system and then it's passed to the real system after a given time offset. Therefore, the real trajectory will follow exactly the same velocity and acceleration definitions made in the Tool_setup, except for the rapid movements that are defined in the axis definition. Is this right?

Thank you very much for all your help

Regards
Edward
 



On Thursday, October 8, 2015 1:55 PM, "Tom Kerekes tk@... [DynoMotion]" <DynoMotion@yahoogroups.com> wrote:


 
[Attachment(s) from Tom Kerekes included below]
Hi Edward,

There is a variable in the latest Test Versions called CS0_DoingRapid that should indicate a Rapid (G0) motion is currently in progress.  But unfortunately I don't think that will help with any lookahead.  Looking ahead in the coordinated motion buffer or the G Code is likely to be very complicated for many reasons.

One approach I've used on various systems in situations like this is to use a digitally delayed trajectory.  In this way the extruder commands can be created and embedded synchronously in the motion trajectory as if the extruder had no delay.  But then by delaying the commanded trajectory (and not the extruder commands) then the extruder commands will occur in the future relative to the trajectory path.  This does involve extra KFLOP Axes.  Normally 3 "dummy" axes are needed to generate the xyz (undelayed) trajectory, and an additional 3 axes to actually drive the motors and follow the delayed trajectory derived from the dummy axes.

If this sounds like something you would want to try I can supply further details.  See the attached example.

HTH
Regards
TK


Group: DynoMotion Message: 12371 From: Tom Kerekes Date: 10/8/2015
Subject: Re: Read execution done from C-program
Hi Edward,

That is correct the trajectory will be exactly the same just delayed in time.

Please see if you can understand the C program and adapt it to your case.

You will probably want to use M Codes as Embedded I/O commands that will occur synchronously with the motion with out any delays or pauses like executing C Programs may have.  See:

If you need to do something different than simple I/O to control your extruder you might have a Thread running in KFLOP to perform those operations triggered by a Virtual I/O Bit change.

I guess we still haven't determined how to turn the extruder back on.  I find it difficult to believe the GCode Generator doesn't provide a mechanism for both on and off.

Regards
TK

Group: DynoMotion Message: 12372 From: Eduardo Barocio Date: 10/8/2015
Subject: Re: Read execution done from C-program
Hi Tom,

Yes, I understood the C program and found it really useful. I really appreciate your help.
On the other hand, that's exactly what I plan to do with the M-codes, and I just realized that I can make a script inside the g-code generator to include whatever I need at the onset of a fast movement as well as at the end of it. 
So, I'll try it and I'll contact you again in case that I run into other specific problems. 
 
Thanks again for all your help. 




On Thursday, October 8, 2015 3:57 PM, "Tom Kerekes tk@... [DynoMotion]" <DynoMotion@yahoogroups.com> wrote:


 
Hi Edward,

That is correct the trajectory will be exactly the same just delayed in time.

Please see if you can understand the C program and adapt it to your case.

You will probably want to use M Codes as Embedded I/O commands that will occur synchronously with the motion with out any delays or pauses like executing C Programs may have.  See:

If you need to do something different than simple I/O to control your extruder you might have a Thread running in KFLOP to perform those operations triggered by a Virtual I/O Bit change.

I guess we still haven't determined how to turn the extruder back on.  I find it difficult to believe the GCode Generator doesn't provide a mechanism for both on and off.

Regards
TK